りすと亭バージョン 4.20.0 リリース・charset抜きtext/plainへの対応強化等

　「メーリングリスト+電子掲示板=リスト板」を実現する「りすと亭」をバージョンアップしました。

　新しいバージョンは4.20.0となります。

　以下より入手できます。

　今回のバージョンアップの変更点をここで解説します。

マルチパートで、正しくUS-ASCIIのcharset抜き"Content-Type: text/plain"はバイナリーに変換しない §

　マルチパートの電子メールの中に、charsetパラメタ抜きの"Content-Type: text/plain"が指定される場合があります。このような指定が行われた場合、RFC的にはUS-ASCIIと見なすのが正当だと思われます。しかし、現実にはこのような指定によってISO-2022-JPやEUC-JP等の日本語テキストを送信する事例が見られました。そこで、安全を取って、このようなパートはバイナリーデータ扱いするよう、Content-Typeをapplication/octet-streamに付け替えていました。

　このバージョンでは、この動作が変更されます。

　まずデータの本体の検査を行い、エスケープコードまたは0x80を超えるコードが存在するかをチェックします。

　エスケープコードがある場合はISO-2022-JPの疑いがあるので、上記のバイナリー化処理を行います。

　0x80を超えるコードがある場合はシフトJISまたはEUC-JPの疑いがあるので、上記のバイナリー化処理を行います。

　それ以外のケースでは明示的にcharset=us-asciiを付加して処理を継続します。

　これにより、正当なUS-ASCIIのテキストは、テキストとして扱われます。

"quoted-printable"で始まるContent-Transfer-Encodingは"quoted-printable"と見なす(spam対策) §

　以下のようなspamが流入していて、かなりの量の例外通知メールが管理者宛に送信されていたので、これを抑止するために入れました。

　[SP]は半角空白です。

　何が起きているのかを説明すると、ヘッダーと本文は空行で区切るのが仕様ですが、この電子メールは空行ではなく半角空白1文字を含む行で区切っています。その結果として、りすと亭のヘッダー解析機能はヘッダの行が継続されていると誤判定し、空行が出現するまでの長い文字列をContent-Transfer-Encodingの値として認識します。これはもちろん"quoted-printable"と一致しないので、処理できないContent-Transfer-Encodingと見なします。

　しかし、今回のバージョンで、"quoted-printable"で始まっていればそれと見なすようにしたので、処理できるContent-Transfer-Encodingと見なします。これによって管理者宛の例外通知メールは飛ばないはずです。